With recent high-speed interface support, packet processing devices for transmitting and receiving data in a packet form have almost reached internal processing speed limits. A policer having a policing function that is configured to be provided for such a packet processing device is expected to perform processes that are more complicated than simply adding and subtracting tokens. The trend for more complicated processing in a policer has become an obstructive factor for high-speed processing.
A countermeasure is desired to address the above conditions since accurate rate control that is the basis for policing may not be ensured.
Japanese Laid-open Patent Publication No. 2004-336549 discloses the related art.
FIG. 1 is a diagram illustrating a configuration example of a packet processing device including a policing function. In FIG. 1, the packet processing device 1 is, for example, a network configuration device having a packet processing function and existing on a communication network, such as a router, a switch, and switching equipment. The packet processing device 1 is equipped with a plurality of (n interface units, where n≧2) input/output interface units IF#1 to IF#n, input/output switches SWs, and a controller CONT.
The input/output interface units (which will be also simply described as interfaces) IF#1 to IF#n and the input/output switches (which will be also simply described as switches) SWs in the packet processing device 1 are mutually connected with each other and connected to the controller CONT via control lines indicated by dotted lines. The input/output interface units IF#1 to IF#n are connected to transmission lines (physical links) TLs of optical fiber and the like.
The controller CONT is equipped with: a processor PR1 that includes a central processing unit (CPU), a random access memory (RAM), and a read-only memory (ROM); and an information saving memory MM1 that is a non-volatile flash memory and that saves an operating system (OS), various application programs, and various types of information (including data), in a re-writable manner.
The interfaces IF#1 to IF#n have interfaces for performing the input and output of user data and the like. The switch units SWs are selectively connected to the interfaces IF#1 to IF#n via switches of switch fabric having a cross-connect function so as to transmit the user data and the like. The controller CONT transmits control information to the interfaces IF#1 to IF#n and the switch units SW, and includes functions such as managing the state of the entire device.
FIG. 2 is a diagram illustrating an example of an input/output interface unit in a packet processing device. The detailed configuration of the input/output interface units IF#1 to IF#n in the packet processing device 1 illustrated in FIG. 1 will be explained with reference to FIG. 2.
In an interface IF (IF#1 to IF#n), optical signals in a packet mode inputted through the optical fiber transmission lines TL are converted into electrical signals by optical modules MDs, and then inputted into a device PHY/MAC having a physical/media access control (PHY/MAC) processing function. Packet mode optical signals outputted through the transmission lines TLs are converted from electrical signals to optical signals by the optical modules MDs. The optical modules MD is configured, for example, using the small form-factor pluggable (SFP) standard that is one of standards for optical transceivers that connect communication devices to a fiber channel and gigabit Ethernet.
In the device PHY/MAC, packets are extracted and are outputted to a traffic processing unit at a subsequent stage of processing, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). The FPGA or ASIC as a traffic processing unit performs traffic management processing such as traffic-policing and traffic-shaping.
The interface IF is equipped with a memory MM2 such as a packet data buffer or a setting table memory, where the packet data buffer and the setting table memory are used when the FPGA and the ASIC perform traffic management processing, respectively. The interface IF is further equipped with a processor PR2 including a CPU, a RAM, and a ROM, so as to be used for a user setting interface and software processing for collecting statistical information and the like.
A detailed configuration of the FPGA or ASIC illustrated in FIG. 2 will be described with reference to FIG. 3 by focusing on a policing function that is one type of traffic management processing implemented by the FPGA or ASIC as a traffic processing unit.
FIG. 3 is a schematic diagram illustrating an example of a policing function. As for a packet inputted into the FPGA or ASIC, as illustrated in FIG. 3, a flow identification unit FL refers to an identifier (ID) conversion table so as to obtain a flow identifier FID (e.g., FID=8) on the basis of a virtual local area network (VLAN) identifier VID (e.g., VID=2) included in the packet, and obtain, as need arises, a group identifier GID (e.g., GID=3). Then, the packet including the above mentioned identifier information as information within the packet, that is, as a payload of the packet, is inputted to a policer PL.
More specifically, a policing function is a function for limiting the traffic inputted into a communication network to a contractual bandwidth. In general, the policing function is often performed per a contractual unit called a flow. The policing function may also be performed per a group unit of a plurality of bundled flows.
These types of flows and groups are recognized in the policer PL by the flow identifier FID or the group identifier GID. The flow identifier FID and the group identifier GID are associated with a VLAN identifier VID that is information inside a packet for identifying a subscriber (user).
However, with support for recent high-speed interfaces, for example, in interface for a speed of 100 Gbps or more, a processing speed inside the packet processing device have almost reached the limit thereof. For example, when supporting a 100 Gbps throughput in the Ethernet, the following maximum packet processing performance is expected.100 Gbps/((64 bytes+20 bytes)×8)=148.8 Mpps,
where “64 bytes” is the minimum packet length in Ethernet, and “20 bytes” is a fixed value obtained by adding the size of the preamble (8 bytes) and the minimum gap between frames (12 bytes). The above value of about 150 Mpps (pps: packets per second) indicates that only two clocks are given as a processing time for one process assuming that the operating frequency of the FPGA or ASIC is 300 MHz. This is derived from the fact that 300 MHz divided by two clocks equals 150 Mpps. The clock speed of 300 MHz is a value near to the limit for the current packet processing devices. Moreover, the processing time of two clocks is said to be an approximate architectural limit when considering that one clock is needed for each of memory reading and writing. That is, the performance required for packet processing has almost reached the limit of the current technologies.
This limit is also applicable to the policing functions in FPGA or ASIC. In addition, recent policers are becoming more complex and are configured to include various policing functions such as, a function of coloring determination (2-rate 3-color policer (for details, refer to RFC 2698 or ME F10 for example)) based on a committed information rate (CIR) and an excess information rate (EIR), a hierarchy type of functions handling tokens overflowing between classes (CoS: class of service), and a group type of functions which perform policing in group units of bundled flows. That is, more complex processing that goes beyond merely adding and subtracting tokens associated with the authority for transmitting packets is required. This becomes one of impediments to the high-speed processing.
FIG. 4 is a schematic diagram illustrating a configuration example of a complex policer. The policer PL1 is equipped with a policing unit 2, a token bucket memory 3, and a token adding unit 4. The policing unit 2 has functions, for example, for determining passing or discarding packets in each flow, for determining passing or discarding packets in each group, for adjusting results between the flows or between the groups, for subtracting tokens from each flow, for subtracting tokens from each group, and for determining coloring.
The token bucket memory 3 in the policer PL1 includes a token bucket counter for each of a flow and a class, and a token bucket counter for a group. The token bucket counter includes a token bucket counter Tc for CIR and a token bucket counter Te for EIR.
The token adding unit 4 includes functions, for example, for supplying tokens to each flow, supplying tokens to each group, supplying tokens that have overflowed the token bucket counters Tc or Te (coupling processing), and supplying tokens that have overflowed classes (hierarchy processing). The policing unit 2 and the token adding unit 4 carry out the functions based on the result of reading out and updating the amount of remaining tokens indicated by counter values of the token bucket counter Tc and Te in the token bucket memory 3.